Coding standards do not make non OO programmers into OO programmers. Only training and experience do that. If they have merit, it is that coding standards discourage the petty fragmentation that occurs when organizations coordinate the activities of diverse groups of programmers.
But you really want more than a coding standard. The structure provided by coding standards gives neophytes one less degree of freedom to worry about, however pragmatics go well beyond pretty-printing standards. We actually need a consistent *philosophy* of implementation. Ex: strong or weak typing? references or ptrs in our interface? stream I/O or stdio? should C++ code call our C? vise versa? should we use ABCs? polymorphism? inheritance? classes? encapsulation? how should we handle exceptions? etc.
Therefore what is needed is a 'pseudo standard' for detailed *design*. How can we get this? I recommend a two-pronged approach: training and libraries. Training provides 'intense instruction', and a high quality C++ class library provides 'long term instruction'. There is a thriving commercial market for both kinds of 'training'. Advice by organizations who have been through the mill is consistent: Buy, Don't Build. Buy libraries, buy training, buy tools. Companies who have attempted to become a self-taught tool-shop as well as an application/system shop have found success difficult.
Vew argue that coding standards are 'ideal', or even 'good', however many feel that they're necessary in the kind of organizations/situations described above.
The following questions provide some basic guidance in conventions and styles.
